Linux SDIO总线驱动

您所在的位置:网站首页 linux spi架构 Linux SDIO总线驱动

Linux SDIO总线驱动

2023-08-11 21:28| 来源: 网络整理| 查看: 265

SDIO卡

       SDIO卡是在SD内存卡接口的基础上发展起来的接口,SDIO接口兼容以前的SD内存卡,并且可以连接SDIO接口的设备,目前根据SDIO协议的SPEC,SDIO接口支持的设备总类有蓝牙,网卡,电视卡等。

       SDIO协议是由SD卡的协议演化升级而来的,很多地方保留了SD卡的读写协议,同时SDIO协议又在SD卡协议之上添加了CMD52和CMD53命令。由于这个,SDIO和SD卡规范间的一个重要区别是增加了低速标准,低速卡的目标应用是以最小的硬件开始来支持低速I/O能力。低速卡支持类似调制解调器,条形码扫描仪和GPS接收器等应用。高速卡支持网卡,电视卡还有“组合”卡等,组合卡指的是存储器+SDIO。

       SDIO和SD卡的SPEC间的又一个重要区别是增加了低速标准。SDIO卡只需要SPI和1位SD传输模式。低速卡的目标应用是以最小的硬件开支来支持低速I/O能力,低速卡支持类似MODEM,条形扫描仪和GPS接收器等应用。对组合卡来说,全速和4BIT操作对卡内存储器和SDIO部分都是强制要求的。

       在非组合卡的SDIO设备里,其最高速度要只有达到25M,而组合卡的最高速度同SD卡的最高速度一样,要高于25M。

 

SDIO总线

       SDIO总线和USB总线类似,SDIO总线也有两端,其中一端是主机(HOST)端,另一端是设备端(DEVICE),采用HOST- DEVICE这样的设计是为了简化DEVICE的设计,所有的通信都是由HOST端发出命令开始的。在DEVICE端只要能解溪HOST的命令,就可以同HOST进行通信了。

       SDIO的HOST可以连接多个DEVICE,如下图所示:

 

 

       这个是同SD的总线一样的,其中有如下的几种信号

1.       CLK信号:HOST给DEVICE的时钟信号.

2.       CMD信号:双向的信号,用于传送命令和反应。

3.       DAT0-DAT3 信号:四条用于传送的数据线。

4.       VDD信号:电源信号。

5.       VSS1,VSS2:电源地信号。

在SDIO总线定义中,DAT1信号线复用为中断线。在SDIO的1BIT模式下DAT0用来传输数据,DAT1用作中断线。在SDIO的4BIT模式下DAT0-DAT3用来传输数据,其中DAT1复用作中断线。

 

SDIO命令:

       SDIO总线上都是HOST端发起请求,然后DEVICE端回应请求。其中请求和回应中会数据信息。

1.       Command:用于开始传输的命令,是由HOST端发往DEVICE端的。其中命令是通过CMD信号线传送的。

2.       Response:回应是DEVICE返回的HOST的命令,作为Command的回应。也是通过

CMD线传送的。

3.       Data:数据是双向的传送的。可以设置为1线模式,也可以设置为4线模式。数据是通过DAT0-DAT3信号线传输的。

SDIO的每次操作都是由HOST在CMD线上发起一个CMD,对于有的CMD,DEVICE需要返回Response,有的则不需要。

       对于读命令,首先HOST会向DEVICE发送命令,紧接着DEVICE会返回一个握手信号,此时,当HOST收到回应的握手信号后,会将数据放在4位的数据线上,在传送数据的同时会跟随着CRC校验码。当整个读传送完毕后,HOST会再次发送一个命令,通知DEVICE操作完毕,DEVICE同时会返回一个响应。

       对于写命令,首先HOST会向DEVICE发送命令,紧接着DEVICE会返回一个握手信号,此时,当HOST收到回应的握手信号后,会将数据放在4位的数据线上,在传送数据的同时会跟随着CRC校验码。当整个写传送完毕后,HOST会再次发送一个命令,通知DEVICE操作完毕,DEVICE同时会返回一个响应。

 

SDIO的寄存器:

      SDIO卡的设备驱动80%的任务就是操作SDIO卡上的有关寄存器。SDIO卡最多允许有7个功能(function),这个同其功能号是对应的(0~7),每个功能都对应一个128K字节大小的寄存器,这个见下面的图。功能号之所以取值范围是1~7,而没有包含0,是因为功能0并不代表真正的功能,而代表CIA寄存器,即Common I/O Area,这个纪录着SDIO卡的一些基本信息和特性,并且可以改写这些寄存器。其中地址0x1000~0x17fff是SDIO卡的CIS区域,就是基本信息区域,Common Information Structure。初始化的时候读取并配对SDIO设备。

       这些寄存器的详细分区已经其对应的功能,在开发过程中都是需要仔细研读的,这些都在协议的SPEC中都有详细说明,这里就不在罗索了。 

 

CMD52命令:

SDIO设备为了和SD内存卡兼容,SD卡所有Command和Response完全兼容,同时加入了一些新的Command和Response。例如,初始化SD内存卡使用ACMD41,而SDIO卡设备则用CMD5通知DEVICE进行初始化。

但二者最重要的区别是,SDIO卡比SD内存卡多了CMD52和CMD53命令,这两个命令可以方便的访问某个功能的某个地址寄存器。

CMD52命令是IO_RW_DIRECT命令的简称,其命令格式如下

首先第一位为0,表明是起始位,第二位为传输方向,这里为1,代表方向为HOST向DEVICE设备传送,其后6位为命令号,这里是110100b,用十进制表示为52,CMD52的名字也由此而来。紧接着是读写标志位。

      然后是操作的功能号。也就是functionnumber。如果为0则指示为CCCR寄存器组。

       紧接着是寄存器地址,用17指示,由于功能寄存器有128K地址,17位正好能寻址。

       再下来8位Write data or Staff Bits的意思是说,如果当前为写操作,则为数据,否则8位为填充位。无意义。

       最后7位为CRC校验码。最后一位为结束位0。

       对于CMD52的Response是48位,命令格式如下:

 

       总结下,CMD52是由HOST发往DEVICE的,它必须有DEVICE返回来的Response。 CMD52不需要占用DAT线,读写的数据是通过CMD52或者Response来传送。每次CMD52只能读或者写一个byte.

 

CMD53命令:

CMD52每次只能读写一个字节,因为有了CMD53对读写进行了扩展,CMD53允许每次读写多个字节或者多个块(BLOCK)。CMD53的命令格式如下:

       第一位是1,为开始位,然后是一位方向位,总是1,代表方向为HOST向DEVICE设备传送,其后6位为命令号,这里是110101b,用十进制表示为53,CMD53的名字也由此而来。

       然后是1位的读写标志。接着是3位功能号,这个同CMD52都是相同的。BlockMode如果1代表是块传输模式,否则为字节传输模式。

       OP Code为操作位,如果是0,代表数据往固定的位置读写,如果1代表是地质增量读写。例如,对地址0固定读写16个字节,相当于16次读写的地址0,而对地址0增量读写16个字节,相当于读写0~15地址的数据。

       然后是17位的地址寄存器,可以寻址到128K字节的地址,然后是9位的读写的计数,对于字节读取,读写大小就是这个计数,而对于块读写,读写的大小是计数乘以块的大小。

       随后的7位为CRC校验码。最后一位为1。

       当读写操作是块操作的时候,块的大小是可以通过设置FBR中的相关寄存器来设置。

       同CMD52命令不同的是,CMD53没有返回的命令的,这里判断是否DEVICE设备读写完毕是需要驱动里面自己判断的,一般有2个方法,1.设置相应的读写完毕中断。如果DEVICE设备读写完毕,则对HOST设备发送中断。2.HOST设备主动查询DEVICE设备是否读写完毕,可以通过CMD命令是否有返回来判断是否DEVICE是否读写完毕。

 

驱动:

以SDIO为例其会采用mmc_attach_sdio来实现驱动和设备的匹配,其本质还是根据sdio_bus的匹配规则来实现匹配。在mmc_attach_sdio中首先是mmc匹配一个bus,即采用何种bus来进行mmc bus来处理host。在这里需要理解一点就是在SDIO中,对于SD卡存储器mmc为实体设备,而对于非SD卡存储器,如SDIO接口的设备,则mmc则表征为bus,这个比较重要。除了mmc bus外还存在SDIO_BUS。

/*  * Starting point for SDIO card init.  */ int mmc_attach_sdio(struct mmc_host *host) { int err, i, funcs; u32 ocr; struct mmc_card *card; BUG_ON(!host); WARN_ON(!host->claimed); err = mmc_send_io_op_cond(host, 0, &ocr); if (err) return err; mmc_attach_bus(host, &mmc_sdio_ops); if (host->ocr_avail_sdio) host->ocr_avail = host->ocr_avail_sdio; /* * Sanity check the voltages that the card claims to * support. */ if (ocr & 0x7F) { pr_warning("%s: card claims to support voltages "       "below the defined range. These will be ignored.\n",       mmc_hostname(host)); ocr &= ~0x7F; } host->ocr = mmc_select_voltage(host, ocr); /* * Can we support the voltage(s) of the card(s)? */ if (!host->ocr) { err = -EINVAL; goto err; } /* * Detect and init the card. */ err = mmc_sdio_init_card(host, host->ocr, NULL, 0); if (err) { if (err == -EAGAIN) { /* * Retry initialization with S18R set to 0. */ host->ocr &= ~R4_18V_PRESENT; err = mmc_sdio_init_card(host, host->ocr, NULL, 0); } if (err) goto err; } card = host->card; /* * Enable runtime PM only if supported by host+card+board */ if (host->caps & MMC_CAP_POWER_OFF_CARD) { /* * Let runtime PM core know our card is active */ err = pm_runtime_set_active(&card->dev); if (err) goto remove; /* * Enable runtime PM for this card */ pm_runtime_enable(&card->dev); } /* * The number of functions on the card is encoded inside * the ocr. */ funcs = (ocr & 0x70000000) >> 28; card->sdio_funcs = 0; #ifdef CONFIG_MMC_EMBEDDED_SDIO if (host->embedded_sdio_data.funcs) card->sdio_funcs = funcs = host->embedded_sdio_data.num_funcs; #endif /* * Initialize (but don't add) all present functions. */ for (i = 0; i < funcs; i++, card->sdio_funcs++) { #ifdef CONFIG_MMC_EMBEDDED_SDIO if (host->embedded_sdio_data.funcs) { struct sdio_func *tmp; tmp = sdio_alloc_func(host->card); if (IS_ERR(tmp)) goto remove; tmp->num = (i + 1); card->sdio_func[i] = tmp; tmp->class = host->embedded_sdio_data.funcs[i].f_class; tmp->max_blksize = host->embedded_sdio_data.funcs[i].f_maxblksize; tmp->vendor = card->cis.vendor; tmp->device = card->cis.device; } else { #endif err = sdio_init_func(host->card, i + 1); if (err) goto remove; #ifdef CONFIG_MMC_EMBEDDED_SDIO } #endif /* * Enable Runtime PM for this func (if supported) */ if (host->caps & MMC_CAP_POWER_OFF_CARD) pm_runtime_enable(&card->sdio_func[i]->dev); } /* * First add the card to the driver model... */ mmc_release_host(host); err = mmc_add_card(host->card); if (err) goto remove_added; /* * ...then the SDIO functions. */ for (i = 0;i < funcs;i++) { err = sdio_add_func(host->card->sdio_func[i]); if (err) goto remove_added; } mmc_claim_host(host); return 0; remove_added: /* Remove without lock if the device has been added. */ mmc_sdio_remove(host); mmc_claim_host(host); remove: /* And with lock if it hasn't been added. */ mmc_release_host(host); if (host->card) mmc_sdio_remove(host); mmc_claim_host(host); err: mmc_detach_bus(host); pr_err("%s: error %d whilst initialising SDIO card\n", mmc_hostname(host), err); return err; }

比较难以理解的是func,这个东东其实是一个实体设备的封装,可以认为其是一个设备。

/*  * Allocate and initialise a new SDIO function structure.  */ struct sdio_func *sdio_alloc_func(struct mmc_card *card) { struct sdio_func *func; func = kzalloc(sizeof(struct sdio_func), GFP_KERNEL); if (!func) return ERR_PTR(-ENOMEM); func->card = card; device_initialize(&func->dev); func->dev.parent = &card->dev;//card设备为sdio设备的父设备。 func->dev.bus = &sdio_bus_type; func->dev.release = sdio_release_func; return func; }

 

上面的code一目了然,其就是具体设备实体的封装,其bus类型为sdio_bus. sdio_init_func仅仅是初始化一个设备,而并没有register。在sdio_add_func实现设备的register,同理就是card实体,在mmc_add_card之前并没有注册,在mmc_add_card函数中才实现设备的注册。

到此设备注册也就完成了,其实sdio总线在形式上类似于usb bus,为什么呢?编写过usb驱动的童鞋们应该知道,编写usb驱动仅仅是编写驱动的加载,并没有具体加载设备实体,导致很多童鞋的困惑,为什么没有设备的加载,其实在usb设备插入时,会动态的创建一个usb设备实体,在usb设备实体创建完成后,根据不同设备id调用相匹配的驱动。而SDIO设备设备也是一样的。上面的code比较混乱,总是让人看不出具体的设备的加载。其实在上面的code中,其中包括了mmc host的驱动。

 



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3